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Abstract 

In this paper we present our results and experiences of using 
symbolic model checking to study the specification of an air- 
craft collision avoidance system. Symbolic model checking 
has been highly successful when applied to hardware sys- 
tems. We are interested in the question of whether or not 
model checking techniques can be applied to large software 
specifications. 

To investigate this, we translated a portion of the finite- 
state requirements specification of TCAS II (Traffic Alert 
and Collision Avoidance System) into a form accepted by 
a model checker (SMV). We successfully used the model 
checker to investigate a number of dynamic properties of 
the system. 

We report on our experiences, describing our approach 
to translating the specification to the SMV language and 
our methods for achieving acceptable performance in model 
checking, and giving a summary of the properties that we 
were able to check. We consider the paper as a data point 
that provides reason for optimism about the potential for 
successful application of model checking to software systems. 
In addition, our experiences provide a basis for character- 
izing features that would be especially suitable for model 
checkers built specifically for analyzing software systems. 

The intent of this paper is to evaluate symbobc model 
checking of state-machine based specifications, not to eval- 
uate the TCAS II specification. We used a preliminary ver- 
sion of the specification, the version 6.00, dated March, 1993, 
in our study. We did not have access to liter versions, so 
we do not know if the properties identified here are present 
in later versions. 

1 Introduction 

Model checking, a technique for analyzing finite state spaces, 
has been applied very successfully to a wide range of hard- 
ware systems. It has been surmised that there are two se- 
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rious impediments that make it difficult to effectively apply 
modeling checking to software systems. The first possible 
impediment is that the technique is limited to handling fi- 
nite state machines, while software systems are generally 
specified as infinite state machines. Jackson [15] and Wing 
and Vaziri-Faxahaxu (22) have addressed aspects of this con- 
cern, showing some techniques for approximating infinite 
state machines with finite state machines that can then be 
used for model checking. The second possible impediment — 
that hardware systems tend to possess certain properties, 
such as regularity, that allow model checking to succeed, 
while software systems may not exhibit similar properties — 
is the one we address in this paper. Specifically, we provide 
a data point by reporting on a positive experience in model 
checking a large software system requirements specification. 
With progress being made on these two fronts, it appears 
that applying model checking to software faces a brighter 
future than previously conjectured. 

In our particular experiment, we translated (Section 3) a 
significant portion of a preliminary version of the TCAS II 
(Traffic Alert and Collision Avoidance System) System Re- 
quirements Specification [11] from the Requirements State 
Machine Language (RSMl) (17] into a form suitable for in- 
put to the Symbobc Model Verifier (SMV) [18]. TCAS II 
is an aircraft collision avoidance system required on com- 
mercial aircraft with more than 30 seats, and was consid- 
ered "the most complex system to be incorporated into the 
avionics of commercial aircraft" [17, p. 6S5]. We were able to 
generate an internal representation of the transition relation 
of the system of an acceptable size so that we could test a 
number of properties of the specification (Section 4). These 
include a number of general robustness properties as well as 
some safety properties specific to the domain (Section 5). 

Our objective was to test the effectiveness of model check- 
ing technology on software systems, so our experiences in 
applying model checking are more important than the in- 
dividual results. We convey some of the obstacles we faced 
and the techniques that we used to overcome these obsta- 
cles to allow us to check formulae against the specification. 
Other software systems that are often specified using finite 
stale machines — for example, telephony and communica- 
tion systems, network and distributed system protocols, and 
other reactive systems — might well yield to similar anal- 
yses. Based on our experience, and as an additional step 
towards making model checking of software specifications 
more practical, we discuss some of the limitations of current 
model checking technology and suggest directions for devel- 
oping model checkers better suited to software (Section 7). 
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Figure 1: Model Checking a Specification 



2 Model Checking 

Model checking is the process of exploring a finite state space- 
to determine whether or not a property holds. Figure 1 is a* 
schematic of the process of model checking a specification/ 
w,th the M>e«nc representations that-we used for the com" 
ponents shown in parentheses. The specification is trans,, 
lated to an input for the model checker, possibly with some 
simplifications. The input and the property that is being 
tested axe then converted to the internal representation- of 
the model checker. The representations are passed to the 
model checking algorithm. The result is either a claim that- 
the property » true or else a counterexample- (i.e. a sequence 
, \l . t ^ slUotls stirt '»B from some initial, state) show. 
k -M r * pr °P crtv IS ^* ^e- result can be ai'aJyzed. 
cation' S rK ' l ° * rcfine ' th * modeKof.the .pecifi-: 

cation the property tested, or even the specification itself, 
iterative process is inherent in our work , • 

The major problem of model checking is that the state* 
spaces arising from practical- problems aie-oflen huge, gener- 
al , }Y S K Ve L CXpIO " ti0 " infe&sibIc - AtfimpJrU*.!. 
^r«.\ , / hCCbng W4S lhc int ^«ction of symbolic 
representations of' state spaces, which allowed direct exolo- 
ral^on of the state space to be replaced- by the manipu UW 
of data structures representing the transition relation of .the 
state space. • ■ - .. . 

In J?" tt " ns J ition reUtio:i ^ reprinted as . boolean 
«Ln °K" * ■'W? has been developed to rep: 

resent boolean functions is the Ordered Binary Decision D% 

ZZ ( ?r^ 0 l BDD r , fo \ 6h 7') A BDD is ..dieted 
dermg of the variables. (One way to- view it is as a decision 
,1 , t 1,°^ rph,c sub - l 'e<* identified.) The properties 
give a un.que representation- of functions, they can be- corn". 

Ute BBDs to test logical relations. Several hardware model 
checkers such as SMV, which we used in our. study, have 

uT»" Th»« rUCted " in 6 B „ DDs « their internal representa? 
tion These are successfuUy used for checking large -circuits 
«n both commercial and academic settings. Theke^forS 
rtt":^T k ^"'V tha ' thC BDD -Potation 
• g J a - rc P reseot ^">» " frequently small althoucli 
variables" deP " dS ™ icai,y °" lhe ordering^ 



ncflT" u ' Ch ,T ked USUaU y "pressed'in a ten,- 
poraJ I logic such as Computation Tree Logic (CTL) (81 
which is used by SMV. CTL i, a branching lime temporal 
ope, extending prepositional logic with temporal operators 
that express how propositions change their truth values ove" 
time In this paper we will only use two.temporal operators 
namely AG and-AF. Each CTL formula^ evaluated wYlh 

star, tfrhT/*"^ SUte - The fo ""«'» AO , holds in 
/ V" • h "* "rtPutation paths 

starting from s and we call such a property an invariant 
The formula AT p holds if p hold, in some state'along aU 
computation , path, starting, from Therefore the formula 
naih. 7 r ^ " " Ue SUte 4 lf ^"S computation 
in . « 8 0,,, • S • whenev « * » 9 will be true 

in sor^.e. successor state along the path. CTL formulae are 
«n>phc.t. y .eva.uated by SMV with "reject to 

3 Translating RSML Specifications into SMV pro- 
- grams r 

to e [he e TeA C r ld T' y the BD ? modd chccki "6 algorithms 
to the TCAS specification, we had to first translate the soec- 
.fication from RSML into a form accepted by a BDD M 
L^d SM^' , - 8UCl, t U , SM ^ Wefirst^briefly ove T view RSML 
Su£K.: ll,e , ; oUndllion ^ »«r description of the 

3.1 RSML ' . 

&fa^L S „« ff,T mU " i " Ung , model simUar^to 

ch bies N 1) A >Mn * h ""™ «««*■« PV»llel state ma- 
chines.. (AND, decomposition) and hierarchical abstraction 
■nto superstates. For the purposes of .this paper, its mos" 
important semantic differences, with Siatecharts are » 
restrictive mferleaving (step) semantics and the separation 
laS^ *^ ^ive. lriB6 enng e^nt and 
Figure 2 i« an example of an RSML state'machine. I» 
,7 s - ^ SlMe h ' eWd,y 4nd lhe Uansitions between the 
h '^Kr7 thr « kind »-of in RSML: OR states, 

.» which: exactly one substate is active at any given time (e g 

sUt«-a« R an ^%r eC,) J ted " .'""V* -(«-S. Qv- .whose sub- 
states_are : R and S). and: atomic .states (e.g. P) which have 
no substates. 'A. substate of. an,ANP stall o, an: OR state 
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Figure -2: An Example of an- RSML stale machine. 
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can be'an ANIfr state; an OR state or an atomic 'slate,' In 
the figure, arrows without origins specify start states. Tor 
example, when the machine enters state Q f it is in states Ul 
and Si. 

A transition consists of a source state, a destination 
state, a trigger event, and possibly a guarding condition 
and/or an output action. A transition is taken when its 
trigger event occurs and its guarding condition (if present) 
is true, thus producing an output action. The output : ac- 
tion identifies an event that may trigger another.transilion. 
in the system. The guarding conditions on a transition are 
expressed in a tabular representation of disjunctive normal 
form called AND/OR tables (see Figure 3.) The far-left col- 
umn of the AND/OR table lists the logical phrases. Each 
of the other columns is a conjunction of those phrases and 
contains the logical values of the expressions. The table 
.evaluates to true if one of its columns is true. A column 
evaluates to true if all of its entries are' true. A dot denotes 
"don't care." When* two or more transitions out of a state 
are triggered simultaneously leading to different next states 
or output actions, the state transition is nondeterministic. 

Figure 3 shows a possible transition from Si 'to S2. The 
transition is taken exactly when trigger event* x is generated 
and the predicate specified by the AND/OR table, is true. 
Eveiit x : may" be triggered by some other transition in the 
system, or by the input interface as a result of receiving. an 
external message from the environment. In the-AND/OR 
table, t is a special variable in RSML that indicates the 
current- time, while t(eritered(Q)) is a function' that Teturns 
the time ' when stale- Q : was last entered: -.Therefore, .the 
AND/OR table specifies the predicate that eitKer* (column 
1) state R is in U and Alt is greater than 1000 ft or (column 



2) the machine entered slate Q at least 5 seconds ago. Alt 
can be. an input variable or a function. If the transition is 
taken, event y will be generated, possibly triggering other 
transitions in the machine. 

The cascading of events continues until no transitions 
are generated. At this point, the system becomes * table. A 
step is defined by the change in the system state from the 
point; at which the initial event was received until the point 
when 'system becomes stable. Each interim state change in 
- a step is called a micro step. A maxima] set of mutually 
consistent transitions enabled at the start of each microti rp 
fires simultaneously within that microslep. A step (and lint* 
a microstep) is assumed to happen instantaneously. Once 
a step is initiated, no external messages can arrive until 
the system becomes stable. This assumption is called the 
synchrony hypo the sit [17]. 

3.2 SMV 

SMV is a BDD-based tool for symbolic model checking of 
finite state systems against specifications written in the tem- 
poral logic CTL (see Section 2). It supports both determin- 
istic and nondeterministic models, and provides for modu- 
lar system descriptions. SMV contains boolean, scalar and 
fixed array data types. Below we summarize only the SMV 
features pertinent to our discussion. 

An SMV .program is divided into modules, each of which 
specifies- a finite state machine. A module contains variable 
declarations to determine its state space and descriptions of 
the initial state and transition relation of the machine, as 
well as a list of. CTL formulae. to be checked. Variable dec- 
larations are preceded by the keyword VAR. The preferred 
method of describing the. initial stale is by a collection of 
parallel assignments to various init(oar) where var is a vari- 
able. The expression- next {var) is used to-refer to the vari- 
able var in the next state. The preferred method of de- 
scribing the transition relation is by a collection of parallel 
assignments to these, next versions of the variables. The 
init assignments are made simultaneously at the start and 
the next assignments are simultaneously executed once per 
step. The values for these assignments can be based on a 
wide assortment of expressions. Assignments are preceded 
by the keyword ASSICH., 

SMV has a macro-like facility for defining a symbol to 
represent an expression. In this case, a variable is not intro- 
duced in the BDD representation of. the system. In addition, 
SMV also extends the semantics of the next operator to ap- 
ply to any expression cxpr that does not contain next. That 
is, riext(expr) gives the value of expression cxpr in the next 
state. This is equivalent to replacing each variable tor in 
cxpr by next(tmr). Symbols are defined after the keyword 
DEFINE.- 

Two sources of nondeterminism in SMV are relevant to 
us. An expression can be a set, and it nondeterministically 
evaluates. to a value from that set. In addition, when the 
initial or the next stale value of a variable is not defined, 
SMV. nondeterministically assigns it a value of its type. 

SMV also has a somewhat more general but less robust 
way. to'specify' the initial state and transition relation us- 
ing.INIT and TRANS constructs. These can .be arbitrary 
proposition al formulae involving the values of the variables, 
symbols, and their ink and next versions. Although we did 
not '.use; this feature; in .our translation of T t CAS, it is use- 
ful for translating some RSML specifications, as we describe 
below. 
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Figure 4: The stale hierarchy drawn a* a tree. The square nodes 
represent AND states and atomic itateV. and the round nodes OR " 
states. 



In SMV, 1 means true and 0 means false. The "aid", 
H or" and "not" operators in SMV are a, | and ! respectively! „ 

3.3 Translating RSML to SMV 

In this section we present an overview of the general method- ' 
ology we derived for translating RSML specifications' into 
SMV programs. 

Hierarchical States One of the keys to successful use oF 
symbolic model checking is to represent objects efficiently.! " 
In translating an ordinary finite state machine into SMV it is" 
most efficient to represent the current state of the machine 
by a variable whose type is an enumerated set consisting 
of the possible machine states; This has the advantage of 
permitting the underlying BDD representation produced to 
be a binary encoding of the state space. 

We extend this idea to a state hierarchy with * parallel 
states in a natural way that preserves the alternation of the 
hierarchy but flattens nested. OR states and nested AND 
states. More precisely, let V be the set consisting of the 
root state, if it is an OR. state, together with ali : OR states 
in the hierarchy that axe children of AND (parallel) states^ 
For each state A t let v(A) be its closest ancestor in V (if \ 
A 6 V then v{A) = A.) Let A be the set consisting, all 
atomic states together with all AND states in the hierarchy 
that axe children of OR states- 

We create one SMV variable for each element A €.v/lts* 
type is an enumerated set consisting of all elements B -eA 
such that v(B) = A. Continuing our example from sec- 
tion 3.1 and following Figure 4, we declare: • . * ■ 

VAR " ' 

*: <P, Q>; 

R: <U1. U2. V); . ; 

S: {SI. S2. S3}; - . . 

The values of these variables completely determine. which 
slates of the machine are current (because .of ,the parallelism 
there may more than one current state.) For;each state B 
cww XPrCS5 whether or not- state B is- current by denning 
bMV symbols according to.lhe following rules: / . 

inB :» 1 ; if B is the root state. ""' * 



inB : - inA; if B is a child of AND stale A, 

inB inA * (A - B) if B.€ A and. ».(£) = A € V, 

inB inBl | inB2 j | inBk;* if'ifl is'aa OR state 

with children Bl , B2 t • • . , Bk and B £ V. 

So for our state hierarchy, we h ave: -. , 

OEFIME " : . 

in* :- 1; - 

in? inH k <« - P) . . in Q ... inM \ . . * 
inR :->,inQ; * . ; i n s :• tnQ:. . 1 

inU -:- inUi J. inU2; . ; / 

inUl :« inR t (R - Ul)VinU2 inR** (R ' •* U2 j • 
inV :- inR k (R - V) ; 

inSl inS k <S'- SI); inS2. inS. *, (S - .S2) • 
inS3 inS k <S - S3); 

Events, Input Variables.'. and the Synchrony Hypothesis 
Each RSML event x U represented by a boolean variable 
x. RSML input variables are ' translated directly as SMV 
variables. If the RSML input variable has an enumerated 
type or is an integer with a specified range, the translation 
is straightforward. If the RSML .input variable, i" an integer 
and. its range is, not explicit*;; we set the range of the SMV 
variable to be sufficiently Urge to encompass the" const an is 
with which it and its .functions axe compared u the specifi- 
cation. ' " • 

* To model f an unpredictable environment we .allow SMV 
to nondeterministicaIly i assign values id the input variables. 
Of course there may .be "certain assumptions, on changes in 
inputs that are necessary for the correct behavior of the sys^ 
tern. If the assumptions are .known, we. can model, them by 
specifying how the input variables change' values.' However, 
allowing SMV to nondeterministically set the variables en- 
ables.us to examine the effects of violating tnese assumptions 1 
on properties .of the system. ' 1 " " '■'* 

We simulate each microstepVof RSML by a step in SMV. 
Therefore, to maintain. ihe synchrony hypothesis of RSML 
we have to restrict the environment to change only when the 
system is stable. So, we define a.synibol Stable, which is a 
conjunction of the negation of all the variables that represent 
events, and use it to guard all changes in input variables. 

For example, assuming x, y and z are the only events' in 
the system we define: 

.DEEfre 

. Stable !x * !y a !z; 

and, assuming- that event x is generated by the environment, 
we assign: . ; ■ 

Assici : ' ■'■ • • ■■ ■ , 

next (it) " " 

'casVe *" '•■ . l . . - . , 

Stable: {0. l) ; 

6; • ^ ..v., ... . , :: * 

esac ; 

In a case expression, the expression before a colon, e.g. 
Stable, serves as a guarding condition. If the guard evalu- 
ates to 1 (true), the case expression evaluates' to' the value 
of the expression after the colon/evg. {0 , 1} (which in turn 
eva, »*Jf? teO or 1 nondeiermiftistically).- The guards are 
considered in order. So the asrign merit specifies that x may 
be generated (set to 1) only if the system u stable in the 
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current st^te. Since all transitions taken that are triggered 
by an event (eitber'internal orfrom the environment) occur, 
in a single RSML microstep, events remain 1 for only one 
SMVstep. ' / 

Timing constrainU Recall that in Figure 3 there is a timing , 
constraint t > t(entered(Q)) + 5 sec, which is equivalent to 
t-t(entered(Q)) > 5 sec. In order to model this constraint, 
we need the diffeTence between the current time and the 
time when "state Q was last entered. ' To avoid storing a 
potentially unbounded value for this difference; -we create a 
variable TincSince .Entered J} to implement a timer: *-' 
j * ■ r . • . 

assicb 

; ■ n«xt<TxBe^Sinco.Entered.Q> . ; 

case • ■ : ' ': ' : 

rint) k next(inQ) : 0; 
Stable ft. Jiae.Since.Entered.g < 5 : 
. _ ,Tiii«.3ince.Entered.Q + 1; ' 

: • • 1 : Tibb.S iricelEnt ered.Q ; . ' . . . „ . 
; >r esac; . . u t • . . . .. .. 

The assignment says that (case l)-if the machine enters stite 
Q, reset the timer, (case 2) if -the machine is stable and the 
timeris less' than 5 seconds, advance the. timer and (c*se- : 
3) otherwise, 'the" timer remains unchanged. Limiting the - 
domains of timers in this way is critical for the efficiency of* 
the SMV translation. t 

Notice* that' this irn piemen tat ion assumes 'that arrivals 
of inputs are -separated -by multiples of one second; Thi* " 
assumption also' happens to be true in TCAS : .' If the time 
granularity is different, we can simply scale the constants 
accordingly, «surrung 'that time is discrete. . v , ■ ■ ' - 1 - • 

transitions * A' transition' in -RSKf I, is' taken if arulohly if (l) J 
the machine is in the source state of the transition, (2) the 
trigger event occurs, and (3) the guarding condition specified 
by the AND/OR table is "satisfied. We define aft SMV sym- 
bol for each transition.'. It is assigned a boolean expression, 
which is a logical conjunction 1 of the above three conditions. 
For the transition in Figure 3 We define: 

DEFIHE ■ • - 1 /. : ' ' * " 

T.S1.S2 — ** 

i n Si source* state 

ft x — trigger event 

ft ( (inU ft Alt > 1000) — guards (col 1) 
I Time.Since.Entered.Q >- 5); — (col 2) 

(Comments in SMV start with w .) For the most part; 
the translation of the guards proceeds directly as in the first 
guard for this example in which inU is defined as above and 
Alt is either an SMV variable or defined symbol whose value 
is compared to the constant 1000. Tine-SinceXiiJeredJJ is 
a timer discussed above. ■ ... 

To model the state change for S, we have an assignment: 

ASSIGH 
- n«t(S) 
i * case 

T S2.S1I T.S3.S1 : SI; . . 

T.S1.S2 j.T.S3.S2 ( : S2; .. , ( •] . •.. 
_ .T_S;1.S3 I T.S2.S3 : S3; . 
. /finS ft next(^nS) : Sli start state 

t . i : S;. , . • " . ' V- . . ' 

eaac; 



where T.S2.S1, T.S3-S1, etc. would be defined similarly to 
T-S1.S2. Notice that the fourth line in the case expression 
specifies that the start state of S is Si. 

Observe that if multiple transitions out of a single state, 
such as T.S1-S2 and T_S1JS3, are enabled siroultaneouily 
(they have the simultaneously fired trigger events and si- 
multaneously satisfiable guarding conditions), then, since 
SMV always evaluates the conditions in a case expression 
in order, this specifies a deterministic transition in SMV 
whereas it specifies a'nondeterministic transition in RSML. 
Jaffc et.al. [16] argue that such nondetermintstic transitions 
are usually design flaws in the specification and should be 
avoided. In Section 5.1 we will describe how to detect un- 
desired nondeterminism in this detexministically modeled 
specification. 

Given these deterministic transitions, output actions (i.e., 
events) are modeled simply as a logical disjunction of the 
transitions that generate them. For example: 

ASSIGH 

next(y) :- T.S1.S2 I T.UI.U2; 

assuming that the transitions from Si to S2 and from Ul to 
U2 are the only transitions that trigger event y. 

Intentionally Nondeterministic Transitions Nondetermin- 
istic transitions between 'different states, such afi would be 
the case if T-S1-S2 arid T-S1-S3 could be simultaneously en- 
abled, are nearly as easy to model in SMV. In this case 
the values of S and next(S) can be used to determine which 
transition has' been taken; For example, we can insert before 
the first line in the case expression above: 

•T.SUS2 a* T.S1.S3 : <S2,S3>; 

The condition states, that if the two transitions are enabled 
simultaneously, the machine will go to S2 or S3 nondeter- 
mirusticaJly. To generate the correct value for next(y) we 
merely need to replace the disjunct T-S1-S2: 

ASSIGN " ' 

: ~. next(y) :- (T1S1.S2 ft next(inS2)> I T.U1.U2; 

This method is convenient when the number of nondeter- 
ministic options out a single state is small (the most likely 
reasonable case) but k such options would entail 2 k - k - 1 
additional cases. 

•A potentially more concise but somewhat more cumber- 
some translation for this situation, using the TRANS state- 
ment of SMV as opposed to the ASSIGN statements used 
above, can be given as follows: - * 

( (T_S1.S2 ft next(irtS2) ft next(y) - 1) I 

(T.S1.S3 ft n«sxt(inS3) ft ..' ) I 

(T S2.S1 ft next(inSl) ft ) I 

(•T.S1.S2 ft !T_S2.S3 ft 'T.S2.S1 ft next(S)-S)) 
ft (KT.S1.S2 ft next(inS2)> 

ft !T_U1_U2 ft next(y) « 0 ) 

The default case for state S would be included in all transi- 
tions that enter state Q. ' * 

In the unlikely case that a reasonable design includes 
parallel transitions between the same two states that- can be 
triggered by simultaneously fired triggering events and have 
simultaneously satisfiable guarding conditions but generate 
different output actions, it is necessary to enlarge the SMV 
variable space by including a variable to record which of 
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Ihe parallel transitions wil) be taken. Corbelt [9, p. 176] 
gives details of a similar translation, although his translation - 
would use similar variables for all states, not just those with 
parallel transitions. 

Miscellaneous Our example does not contain all RSML 
constructs, such as PR£V(), constants, macros, functions, 
statechart arrays, and transition buses. Roughly; RREV(e) ' 
returns the previous value of expression t. Modeling Prev() ' 
requires introducing an auxiliary variable to "remember 1 " the 
variable's previous stale Constants can be trivially imple-: 
men ted with SMV defined symbols, which do not add vari- 
ables to the BDD representations. Macros and functions 
without arguments can be modeled similarly. Macros and 
functions with arguments axe somewhat trickier; they can 
be implemented as SMV modules that are instantiated at 
each call cite. Statechart arrays can be implemented as an 
array of modules. The translation of transition buses is no 
different from that of ordinary transitions. 

Comparison with Statechart* ' In contrast to RSML step 
semantics, Statechart step semantics (as defined by Pnueli 
and S h ale v [19]) build a set T of transitions that will -fire., 
in a step by iterative!/, computing a closure based on the 
enabled transitions at the start of the step. Only after the 
closure is computed do the transitions fire. This appears to. 
be less efficient to model in SMV since one would* seem- to 
need an extra boolean variable for each transition' in order 
to record whether or not it is in" the set 7* computed during 
each step. - • :. ; *: 

4 Obstacles to Model Checking TCAS II with SMV 

After we derived the translation' rules in the previous section j : 
we had to overcome, a number of obstacles to make model.' 
checking the TCAS II specification feasible. 

4.1 TCAS II 

TCAS II is an airborne collision avoidance system required' 
on most commercial aircraft. The TCAS- equipped aircraft' 
is surrounded by a protected volume of airspace/ When an- 
other aircraft intrudes into this volume, TCAS II generates 
warnings, (traffic advisories) and possibly escape maneuvers' 
(resolution advisories) in the vertical direction to the pilot' 
to avoid collision. Examples of resolution advisories (RAs) 1 
include Climb, Descend, Increase- Climb ("increase the cur- 
rent climb rate"), Increase- Descend, Climb- VSLO ("do not 
descend" ), Climb- VSL50O (*do not descend more than 500 
ft/min n ), etc. " - * . 

The specification of TCAS II, a 400 page document, was 
written in RSML. The first- obstacle to analyzing the speci- 
fication was its sheer size. As a first attempt we decided*. to 
try to model check' a portion of it, namely a state machine 
called Own- Aircraft, which occupies about 30% of the spec- 
ification. Own- Aircraft has close interactions -with another 
part of TCAS called Other- Aircraft, which tracks the state 
of other aircraft in the vicinity and possibly generates RAs. 
Up to 30 other aircraft can be tracked. -From the RAs given 
by ail the instances of Other-Aircraft, Own-Aircraft derives 
a composite RA and generates' visual and audio outputs: to 
the pilot. Figure 5 shows the state Composite- RA, 'one br 
the twelve parallel substates of- Own- Aircraft. ;v 
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Figure 5: Composite-RA in Own-Aircraft 

\ - V. * . ; .' 

' We treated Other- Aircraft as part~of the environment of 
Own-Aircraft. That is, we created variables, for any states 
of Other- Air craft that are referenced within- Own-Aircraft. 
Like environment 'variables; their values were nondetermin- 
istic, except that we restricted when these variables could 
change to. ensure correct Synchronization:' We focused on 
resolution- maneuvers' with one- intruder aircraft and thus 
modeled only one -instance of Other- Aircraft* ; 

4.2 ; fcqos ; ^ ; ■ - ' 

We' knew a -priori that there is no efficient BDD representa- 
tion for multiplication and division .under .any variable or- 
dering {3, 20] so* we realized that wc needed to avoid them. 
Two functions in Own-Aircraft do involve multiplication and 
division' of values for measured . altitudes and altitude rates. 
These are measurements of input variables that' we already, 
modeled nondeterministically; . So we made the conserva-. 
tive simplification to treat the calculated values as n on de- 
terministic themselves. (We also eliminated from our model 
several- input variables that are only referenced by .the, two 
functions.) These simplifications did dot cause problems for 
the properties that we checked and '.report* infection 5. 

4.3 SMV 1 1 / 

-The performance of. BDD-based algorithms is directly re- 
lated to the size of. the BDDs. Some of our early attempts at 
checking generated enormous BDDs: at. one point the BDDs 
consumed.200 MB.of physical- memory,. and other runs were 
terminated- before, the BDD was constructed. Our attempts 
to check formulae with the large BDDs were generally un- 
successful or'too slow (our initial success in identifying non : 
determinism was an overnight run, although we can now find 
the nondeterminism in a few minutes). 

: The -size' of the BDDs can be reduced by dynamic vari- 
able reordering and conjunctive partitioning [6], which are 
supported by. SMV. These techniques- dramatically improved 
the performance of checking some formulae;, however, they 
' did not solve all the problems. The- v BDD;size was very sensi- 
tive-tonne ranges of the variables representing altitudes and 

... ? -Thit, sept ion refers to, SMV Release' 2.4 A Which was' the most 
recent* vent on' to which we had access*. ■ * -* 
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Properties 


Result 


Time ' 
(sec.) 


No. of BCD'. 
* Nodes 


Memory 
Allocated (MB) 


Building the Transition Relation 


N/a 


46.6 


124618 


7.1 


Transition Consistency 


False 


387.0 


717275 


16.4 


Function Consistency 


False 


289.5 


387167 


11.5 


Step Termination 


True 


57:2 


. 142937 


7.4 


Descend Inhibition 


True 


166.8 


429983 


11.8 


Increase- Descend Inhibition 


False 




282694 . 


9.9 


t Output Agreement; 


False 


325.6 


37671.6 


11.6 



_ . . , _ \ '• , J„ lU^ -^nVrki.?* " The result column indicates whether the property wai true. The (u»er + system) 

running SunOS 41.3 with 128 MB .of main memory. 



altitude rates. Take altitudes for an example. The specifica- 
tion stales that some altitude variables have granularity as 
fine as "1 to 10 feet;" The. ranges of some .altitude variables 
are not specified, but they arecompared to constants whose . 
values range from 400 feet to 30500 feet.. Therefore at least , 
13 to 15 bits are needed to represent, altitudes. However, 
we found that with these values we could not. get the model, 
checker to build the BDDs ia.a reasonable amount of time. 

Initially we got around the problem- by, redefining the. 
constants so that they fitted in a small range., for example, 
from 0 to 15 for altitudes and -4 to 3 for altitude rates. 
(Increasing the numbers by one bit sometimes exploded the 
checking time from ten minutes to more than ten "hours.)' 
Although we- were able to build the BDDs in this way and 
check some formulae, this ad hoc .solution was unsatisfac- 
tory in many ways. An obvious drawback is that because: 
of the small ranges, some distinct constants in the specifica- 
tion became identical. after the mapping (for example, both 
400 feet and 1000 feet might become 1). This caused some 
formulae that are false for the specification to evaluate to 
true for the model. . ; 

We could not' leave the results of addition- and cpmpari- 
son nondeterministic as we did with multiplication, and di- 
vision in Section -4. 2 because addition and. comparison are: 
essential to the logic of Own-Aircraft. For example, any De : 
scend RA is prohibited when the difference between the cur- 
rent altitude of the own aircraft and the estimated ground 
level altitude is less than some threshold. If the subtraction 
or the comparison were modeled riondeterministically, this 
safety requirement would be violated trivially. 

We eventually realized that the problem with the ranges 
was due to the variable ordering for- the BDDs that SMV 
was using to represent integer addition and comparison. The 
BDD for any bit of the sum of the integers X = xj*a * :r„ 
and Y = yi yj * • y« has si2e O(n) if the variables are in the 

order x{ , y, , r 3 , y a x„, y n but requires exponential site -if 

the variables are in the order xj.xa, . ■ • *n,yii • ■ .y«- SMV 
does not interleave the bits among the variables it. is repre- 
senting when constructing the BDDs. Therefore; although 
comparison* and addition have concise BDD representations, 
SMV produces exponential size BDDs for them. 

We considered two ways of attacking this problem, namely 
changing the internals of SMV to interleave the bits; or doing 
addition and comparison at the source code-level. Although 
in principle tne former may be a better long' term solution, 
the latter method seemed a simpler approach and We were 



able to use it with great success. We wrote some simple awk 
scripts for preprocessing the SMV program to allow param- 
eterized macro expansion, loop unrolling, etc. Using these 
facilities, we implemented efficient addition and comparison 
in the. SMV program and manipulated all the integer vari- 
ables and constants- at the bit level. We can now model the 
altitudes and altitude rates with the precisions required by 
the specification. 

Another performance problem was that generating a coun- 
terexample often look hours even though the formula was 
determined false within minutes. Evaluating the formula 
and finding a counterexample (in case the formula was false) 
were done by the model checker as two separate searches in 
the reachability graph. For example, to check for an invari- 
ant property with the formula AG p (i.e. p is true in all the 
reachable states), the model checker started from the set of 
"bad" states (in which p is false), and searched the set of 
states that could reach the tt bad n states by iteratively apply- 
ing the backward transition relation. If this set contained 
any initial state, the model checker would determine the 
formula false and start a second, forward search from such 
an initial state to find. a counterexample. We have modi- 
fied- the model checker by storing certain state information 
duririg the first search, eliminating most of the work in the 
second search. As a result, once a formula representing an 
invariant property is evaluated false, a counterexample can 
now be found almost instantly. 

5- . Results of Model Checking TCAS II 

Once we overcame these obstacles, we were ready to do some 
analysis of the specification using the model checker. The 
properties that we analyied include general properties that 
should hold in most RSML specifications (Sections 5.1. 5.2, 
5.3 and Section 5.6) and domain-specific properties (Sec- 
tions 5.4 and 5.5). ■ 

Table -1 reports the resources needed to analyze the prop- 
erties.. The BDD. representation of the SMV program has 
227 boolean variables, 30 of which are for events, 36 for the 
states- of Own-Aircraft, 19 for the states of Other- Aircraft, 
134 for altitude and altitude rates, 22 for inputs other than 
.altitude and altitude rates, and 6 for other purposes. The 
siie of the state space is. about 1.4 x 10 fl *. The sue of the 
reachable state :space J is at least 9,6 x 10 . 

3 We obtained this lower bound by executing SMV with the com- 



162 



BNSDOaD' <XP 636208A_J_> 



Dis played -Mod el- Goal = < 



M uk( O wn-Ttack- Alt- Rate , 
Prev^Displayed-Model-Coal). 
1500 ft/min) 



Mio( Own- Track- AH- Rate, 
Prev( Displayed- Model- Coal), 
. -1500 ft/min) 



2500 ft/min 
-3500 ft/min 

Majc(Owrv- Track- Alt-Rate,' 
1600 ft/min) 



Mtn(Own-Track- Alt-Rate,. 
-1500 ft/min) 



If Composite- RA not in state Positive . /*.ca*e 1. 

case 2 



if (New-Climb or New. Threat) and 
not New-. Increase- Climb and 
not (Increase- Climb- Cancelled or 

Increase-Deacend-CancttUed) and 

Compotite-RA in state Climb 

If (New-De*cend or New- Threat) and 
not New-lncrease-Descend and 
not (Increase- Climb- Cancelled or 

In crease- Descend* Cancel led) and " . . 

CompotiterRA'tn' stota Descend • 

If New^'lncreaaVClimb "*/ 1 

If -New- In crease- Descend "-:!';.-.-. . 

If : Incrsmsc-Climb-Cancelled and t .. . 

not New- Increase-Climb and 
Compotite-RA in state. Positive ' 

*'■ - - ■ . ■ 

if Increase-Descend- Cancelled and 

not New-Increase-Descend and . . i 
Composite- RA in state Positive 



i 

/r 



7. 
7 



/• case 3 •/ 



case 4' 
case 5 
case 6 



./* ca»e 7 



V . 
•f ■ 



r 

•A 



P re v(Diiplayed- Model-Goal) Otherwise 



/• case a y 



Figure 6: Definition of Displayed- Mo dd-Goal in the TCAS specification. Most of the identifier* arc RSML macros or. abbreviations, 
the definitions of which are omitted here due to limited space. (Their truth: values depend on Composite- RA and Other,- Aircraft.) 



5.1 Transition Consistency 

There, axe known nqndeterministic transitions in earlier ver-~ 
sions of the TCAS specification. So, our first attempt was' 
to find such transitions in one of these versions with' the 
model checker. - (For the other properties. that we checked, 
we worked with a later draft TCAS specification [11 J, in 
which there is no unintentional nondeterminism.). . These 
nondcterministic transitions, had previously been identified 
by Heimdahl and Leveson (13) using a different technique. 
We were interested in checking these properties to verify 
that model checking could match previous results. In Sec- 
tion 6 we will summarize the differences between our model 
checking approach'ahd the technique used by Heimdahl and 
Leveson. 

In our example in Figure 2, there are- possible nondcter- 
ministic transitions from state S. For example, the transi- 
tions from Si to S2 and from Si to S3 would be enabled 
at the same time if their trigger events were the same and 
their guarding conditions were simultaneously satisfied. We 
can check this with the model checker by the following CTL 
formula: 

AG !<T_Sl.S2 t T.S1.S3) 

Recall that TJ51-S2 is true.when the transition from Si to 
S2 is enabled; similarly foi T-S1-S3, . So. the CTL formula 
specifies that the two transitions are never enabled simulta- 
neously. Applying this technique to all the states, the model 
checker was able to find the nondcterministic transitions in 
that version of the specification. - *. : > 

" - " " -v*. ; *i 

mmnd line option -f but without running it to completion. This option 
forces SMV to find the reachable state space before evaluating any 
formula. 



5.2. Function Consistency - ' . 

DispUyed-M6d el-Goal, shown irv Figure 6 is 'a function whose 
value is displayed to the pilot. It represents the optimal alti- 
tude rate. at which the pilot should aim {a positive value indi- 
cates the upward direction): The function definition consists' 
of eight cases, which are supposed to be mutually exclusive. 
It is not obvious whether this is the case since the mutual 
exclusion, depends on logic elsewhere in the specification. 

Checking for mutual' exclusion of the cases is similar to 
checking for nondeterminism. : We defined a boolean symbol 
Case-1 for the. first Case, and Cae-e-2 for the second case, 
and so on, and checked ~an CTL formula' of the form: 

AG !<(Caa«-l ft Caaa-2) 1 (Case-1 ft r Ca B e-3) I 
... I (Cae4-6 k Caa«-7>> ' * 

The raodcl chccker found a counterexample -showing that the 
formula was false. After carefully examining the counterex- 
ample, we decided that the scenario was due to the oversim- 
plified model of Other- Aircraft, which we had considered as 
a part of the non deter minis tic environment. In the coun- 
terexample, Other- Aircraft reverses from aii In crease- Climb 
RA to an Increase- Descend ,RA in one step, which is prohib- 
ited by the logic in the specification. After we changed the 
code to prevent Other- Aircraft from making such spurious 
transitions; no counterexamples were' found. 

5.3 S.tep Termination 

A step in an US ML state machine may not terminate if the 
.machine contains a cycle of events under the transition rela- 
tion. However /usuafl^ the events' in an RSML specification, 
such as the TCAS specification, form a partial ordering un- 
der the transition relation, so it is easy 'to see that the state 
machine, will always terminate. Alternatively, in our frame- 
work we can check for termination with the CTL formula:. 
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AO ('Stable -> AF Stable) 

which states thai 'whenever the state machine is not stable, 
it will always become stable eventually. This formula was 
evaluated true for our model of the TCAS specification, as . 
expected. 

S.4 Inhibition of Resolution Advisories 

A TCAS document [10] states- that* (1) . all. Descend RAs 
are inhibited when the own aircraft is below 1 000 feet above 
ground level, and (2) all Increase- Descend RAs are inhibited 
below 1450 feet above ground level. The logic thiit guaran- 
tees these safety properties resides in both- Own- Aircraft. and . •■ 
Other-Aircraft. We imposed the necessary constraints on 
the transitions of Ot her- Aircraft in, of del to check whether ■ 
the part of the logic in Own-Aircraft'is correct. The model, 
checker found that while the first property is satisfied, the 
second is not*. The formula that we checked for the- second 
property was similar to the following: 3 * , . ■ '\ 

AG ( (Radio-Alt ineter-Statua • Valid 
fc Own-Alt-Radio <• 1450) 
-> ! Increase* Descend) 

where Oro-Alt -Radio is an input representing the altitude of * 
the own aircraft above ground level, Radio-Alti»et«r-Status 
an input indicating whether Own-Alt -Radio is valid, and 
Increase-Descend an expression evaluating to true when 
an Increase-Descend RA is issued. The 1 ^counterexample it 
gave revealed a typographical error in a guarding condition 
in the specification ; (> instead of <).\ J The effect of the er : ; 
ror was that the. Increase- Descend RA was inhibited for only 
one step, thus aUowing. the safety property to be violated. 

5.5 Output Agreement . 

In addition to the value of Displayed- Model-Goal; the state 
of Composite-RA in Figure, 5 is also shown to the pilot. 
Therefore it seems safety-critical that Composite-RA and 
Displayed-Model-Goal agree with each other; We checked 
for several such properties. For example, one would expect 
that if Composite-RA is in state Climb, then Displayed- 
Model-Goal should be at ieast 1500jt/min. , However, the 
model checker revealed that this is not true. In fact, it 
showed that when Composite-RA is Climb, Displayed-Model- 
Goal could be negative. The CTt formula we checked was 
roughly: 

AG (Conposite-RA - Cliub -> 

. Displayed-Hodel-Goal >* 1500) 

The counterexample given by'the model checker was a three 
step scenario: 

1. At time to, there is an intruder aircraft and Other- 
Aircraft gives a Descend RA. As a result, Composite- 
RA is in state Descend and by case 3 of the definition 
of Displayed-Model-Goal, it is '< -1500 lt/min. 

2. At time U > *o, Other- Aircraft realizes that an in- 
crease in descend rate is necessary and issues' an Increase- 
Descend RA, which puis Displayed- Model-Goal at ^2S00 
ft/min by case 5. . ....... 

3 The actuai formula* differ slightly due' to »m'« implementation 
details. - - . : • ' i I . .. * * * '"J ' 

*Th* author* had discovered the typographic*! trror by observa- 
tion during the translation process. 



3. At time <j +1, the situation has changed and Other- 
Aircraft projects that a climb would result in greater 
separation from the intruder. So it reverses its RA to 
CUmb, making Composite-RA enter state Climb. At 
that point, case 7 applies and Displayed-Model-Goal 
becomes < -1500 ft/min, resulting in contradictory 
outputs. 

5.6 References to Uninitialized Values 

It is possible for an AND/OR table or function to refer ic. 
the previous value of some variable (e.g., an input variable, 
slate, or function reference) even though the variable was 
not yet defined in the previous step. In such a case the 
value of Prev() is undefined. The model checker handles 
such undefined references in the same way that it handles 
environment variables. That is, it nondeterministically as- 
signs values in an attempt to find a counterexample to the 
formula.' So while analysing for the properties mentioned 
above, the model checker also discovered situations in which 
a variable is referenced before it is defined, e.g., referring to 
PrevQ in the first step. 

5.7 Discussion 

As shown in Section -5.2, the model checker sometimes found 
incorrect counterexamples due to the simplifications of the 
system that we made. It may seem that the repeated process 
of getting an incorrect counterexample and eliminating it is 
an undesirable artifact of the incomplete translation of the 
specification. There are several reasons why leaving part of 
the model nondeterministic is in fact a useful technique: 

- • A specification may be So complex that model checking 
it in its entirety is infeasible. This- approach, then, . al- 
; lows model checking to be beneficially applied to parts 
• : of the specifications without fully considering- all the 
remaining components. 

• A software engineer can use .the information obtained 
from analyzing the counterexamples to clarify the re- 

• lationship between parts of the specification, in par- 
ticular between those parts that are fully modeled and 
those that arc partially modeled. 

• Development and analysis of the specification can be 
interleaved so that potential problems can be found 
or avoided earlier. For example, when developing the 

* TCAS specification, an engineer could have specified 
Own-Aircraft first and have left Other-Aircraft nonde- 
terministic. Then an analyst could have model checked 
Own-Aircraft and discovered the assumptions on the 
behaviors of Other- Aircraft that are necessary for Own- 
Aircraft's correct operations. This information then 
could have been used to develop Other- Aircraft, which 
could be model checked later to see whether the as- 
* sumptions hold. 

This iterative approach appears to have benefits for anal- 
ysis and shows potential for iterative development of speci- 
fications, as well. 
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6 Related W rk 

Sreemani arid Atlee [21], in work independent of ours; an- 
alyzed the A-7E aircraft software requirement specification 
with SMV, and were also able to successfully check several 
temporal properties. While their motivations were similar, 
our studies differ in several ways because of differences in the 
specifications. The A-7E aircraft requirements were written 
in the Software Cost Reduction (SCR) requirements nota- 
tion [1, 14], which does not contain features such ashierar- . 
chical states and does not make assumptions like the syn- 
chrony hypothesis. In addition, -the environment of the A- 
7E specification is abstracted as a set. of predicates, whereas 
the inputs to our system include numerical values. Numer- 
ical calculation and comparison are abundant in the TCAS 
specification,' and they introduce significant problems in the ' -. 
model checking process. 

There are a number of other widely researched approaches 
to handling the state space explosion problem. Corbett re- 
cently classified these techniques into several categories [9].. 
In contrast to our work,. which studies a single data point * 
for a single approach, Corbett compared three approaches, 
model checking, partial order space state reduction, and in- 
equality necessary conditions, all in the context of detecting 
deadlock in Ada tasking programs. For deadlock, Corbett 
observed that "no technique was clearly superior to the oth- 
ers, but rather each excelled on certain kinds of programs [9, 
p. 179}." 

The two translations into* SMV that Corbett used differ 
from ours. One translation represented asynchrony by arbi- 
trary sequential interleaving of transitions, eliminating the 
parallelism that we exploit. The other translation, which he 
found less successful, represented asynchrony in parallel list- 
ing extra variables to indicate which transition -was executed 
in each state machine whereas our translation only requires 
extra variables where parallel nondeterministic transitions 
occur between the same two states.. Use of our translation . . 
may have changed the outcome of Corbett's comparison, but 
further work is needed to determine which approaches are 
most effective for checking particular properties on certain 
classes of systems. 

Helm da hi and Leveson [13] jtook a different approach.- • 
They analyzed the TCAS specification without exploring the 
state spice. They deduced global properties of the system 
by composing results of local analysis. Their technique differ 
from ours in two ways. 

First, the properties that we checked were different. Their 
concerns were transition consistency and completeness [16], 
which are domain-independent robustness properties. In 
Section 5.1 we discussed how we checked for a source of 
transition inconsistency. (They also discussed other sources 
of transition inconsistency, which we have not addressed.) 
Completeness intuitively means that a response is specified 
for every input; more specifically, it means that the disjunc- 
tion of the guarding conditions of all the transitions with 
the same triggering event from a particular state form a 
tautology. In principle this can also be checked in our frame- 
work similar to the way consistency is checked. In general, 
our approach permits analysis of properties that can be ex- 
pressed as CTL formulae, and is therefore capable of check- 
ing domain-specific properties as well (Sections 5.4 and 5.5). 

Second, their tool is more efficient for checking transition 
consistency and completeness. On the other hand, it some- 
times produced many spurious errors due to the predicates 
involving arithmetics in the AND/OR tables, because the 



predicates were modeled 'as' independent [boolean variables. - 
To eliminate the spurious reports- they would .have to find, 
out the relationships among the predicates. In contrast, we 
modeled the numbers directly in the BDDs and interleaved, 
their bits in the binary representation to improve perfor- 
mance. In this way, we were able to handle addition and 
subtraction. Because we explore the reachable state space ■ 
we generate fewer spurious errors. 

_ r .; > 

7 Conclusions . , 

We have shown that it is 'feasible to 'translate part opa large 
finite state specification ' into* a form " suitable for "a model 
checker, and have been able to check several non-trivial 
properties. Our approach to analyzing the specification iter- 
atively, by modeling- some components nondeter minis tic illy 
and then refining them, proved to be quite powerful.' These 
are critical steps towards, realizing symbolic model check- 
ing as an effective tool in the process of analyzing software 
specifications. * .... - - t 

What else is needed to make model checking as ubiqui- 
tous for' software, systems as it .is already for : hard ware sys- 
tems? This is hard to predict, with certainty, but a number 
of directions seem especially promising. 

First, Bryant and Chen [4] introduced the BMD (Bi- 
nary Moment Diagram), a data structure: that, in .contrast 
to BDD's, can be used* to represent multiplication concisely. 
With* a variant of- this data' structure; the *BMD, they were 
able to verify division circuits.' A* hybrid - approach where 
B MP's .are used to represent arithmetic variables and BDD's 
are used to represent "control variables, as suggested by Clarke 
and Zhao [7], may be attractive. Building Jm'odel checkers 
that can handle arbitrarily complicated numeric calculations 
is almost. certainly-intractable. However, rudimentary arith- 
metic, coupled with. an understanding of the appropriate no- 
tions of approximation, might- be sufficient to handle many 
applications. . . t 

Second, automating the translation from RSML to input 
for SMV (or another model checker) appears to be straight- 
forward. It might be reasonable to develop a model checker 
that< directly -accepts languages such . as RSML or. State- 
charts 1 ; eliminating the- need for -'any 6 - ource4evel transla- 
tion at all. This is a good example, of a place where model 
checkers developed specifically for software might have some 
leverage, since the way in which engineers define the state 
machines often seems to differ between Hardware and soft- 
ware. ' ' ; • 

Third, it might be possible to exploit the general struc- 
ture of "the derived transition relation to' improve 'perfor- 
mance. (Although we only showed how to translate the 
TCAS specification, we believe that this is a generalizable 
approach.) Our SMV description of an RSML specification 
had variables to represent the state space, time, environ- 
ment, and internal events. Although we treated these uni- 
formly in our translation to SMV-, they were used in different 
ways: .It .'is possible that a model checker that incorporated 
some of the semantics of lime into the internal algorithms 
could outperform a checker that handled time with ordinary- 
numeric variables. More generally, by exploiting common 
properties- of software- specifications that represent process 
control systems like TCAS, one might be' able to build model 
checkers that perform better and are easier to use. 

^We .believe that this investigation contributes' to an in- 
crease' in optimism that symbolic model checking can over- 
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come predicted impediments and thus be successful in -the, 
analysis of realistic software specifications. 
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